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Аннотация 
Введение. В научной литературе рассматриваются разные подходы к менеджменту качества в сфере информационных 
технологий (ИТ). Проработаны вопросы выявления и исправления дефектов, показаны возможности их минимизации. 
Есть материалы об управлении качеством в сложных технологических процессах. Доказано, что работа с качеством 
цифровых продуктов требует в числе прочего прояснения вопросов качества кода. При этом нет детального описания 
управления качеством на каждом этапе жизненного цикла ИТ-продукта, включая тестирование. Отметим, что коорди- 
нация релизов (выпусков) программного обеспечения тесно связана с управлением качеством, однако данный процесс 
редко или фрагментарно рассматривается в литературе. К тому же не учитывается взаимодействие процессов, поэтому 
нет комплексного представления об управлении качеством при создании, тестировании и доработке программного 
обеспечения (ПО). Данное исследование призвано восполнить указанные пробелы. Его цель — представить комплекс- 
ный подход, связывающий теорию, практику и методы управления качеством ПО. 

Материалы и методы. Исследована, проанализирована и отреферирована профильная теоретическая и приклад- 
ная литература. Задействован профессиональный опыт автора в управлении качеством ИТ-продуктов. Учтены 
практики глобальных поставщиков цифровых товаров и услуг. Автор использовал эти материалы и методы для 
детальной проработки вопросов тестирования ПО и развертывания кода. 

Результаты исследования. Сформирована, описана и представлена в виде схемы комплексная модель управле- 
ния качеством при создании ПО. Выявлены ее взаимосвязи с моделью менеджмента проектов и жизненным цик- 
лом продукта, а именно: анализом, дизайном, разработкой, тестированием, развертыванием и поддержкой. Ука- 
заны принципы управления качеством на каждой из этих стадий. Систематизированы и представлены в виде 
схемы процессы и проверки при развертывании кода. Показаны их особенности в трех средах: при разработке, 
тестировании и производстве. 

Обсуждение и заключение. Алгоритм позволяет специалистам по качеству выстроить последовательность дей- 
ствий для исключения в будущем выявленных дефектов, понимания ситуации, когда можно (или нельзя) развер- 
тывать код и определения момента, когда следует передать ПО пользователю. Кроме того, предложенная схема 
может быть базой для автоматизации развертывания кода. Решение позволит сократить время на разработку. Как 
следствие, продукт быстрее выйдет на рынок, что ускорит окупаемость затрат. Внедрение в производственную 
практику ИТ-компаний модели, созданной в рамках данной научной работы, предполагает стратегические изме- 
нения. Их реализация требует значительных затрат времени и других ресурсов, поэтому общий процесс транс- 
формаций следует разбить на части. Предложенный подход адаптируется под нужды различных организаций и 
продуктов. Можно работать с отдельными компонентами, чтобы создать оптимальный план для достижения це- 
лей по управлению качеством. 
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Введение. В условиях высокой конкуренции на рынке программного обеспечения (ПО) пользователи ориен- 
тируются не только на маркетинговую, но и на потребительскую ценность товара, обращают внимание на удоб- 
ный интерфейс, оперативность и стабильность работы. Все это следует учитывать производителям и подразде- 
лениям софтверных компаний, которые работают с качеством. В открытом доступе достаточно теоретических и 
прикладных публикаций, посвященных управлению качеством и автоматизации этих процессов. Авторы рас- 
сматривают новации в этой сфере, сравнивают их с традиционными практиками. 
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Работа с дефектами (в частности, их раннее выявление и анализ) позволяет предотвращать ошибки на этапе 
разработки софта. При таком подходе сокращаются затраты времени, денег и других ресурсов на исправление 
логических, синтаксических, компиляционных и других ошибок ПО. Улучшается качество продукта, повыша- 
ется его ценность в плане надежности, легкости обслуживания и экономичности [1]. В [2] описано управление 
качеством в сложных технологических процессах. Автор показывает, как выявить взаимосвязь между техноло- 
гией и качеством. По его предположению, существует информационное соответствие между вероятностыми мо- 
делями технологии и качеством. Из [3] известно, что в сфере информационных технологий (ИТ) увеличение бюд- 
жета на 49 % приводит к созданию новых моделей управления качеством. В качестве примера можно назвать 
стандарты 1ЗОЛЕС [4]. В [5] показано, как управление качеством влияет на производственные процессы. 

Важная и сложная задача — автоматизация контроля процессов, от которых зависит качество. Ключевая 
форма контроля — статистическая. Она работает с индикаторами, критичными для качества конечного про- 
дукта (от англ. спаса! 0 диаШу (СТО)). Эти показатели отслеживаются и сравниваются с целевыми значени- 
ями. В результате получают заключение о статистической управляемости или неуправляемости процесса [6]. 

Анализ жизненного цикла разработки ПО рассмотрен во многих источниках, однако нет детального описания 
управления каждым этапом жизненного цикла, включая тестирование [7]. 

Отдельное направление исследований — взаимосвязи между основными инструментами менеджмента каче- 
ства и их влияние на операционные, финансовые и рыночные показатели компании-производителя. При этом 
интегрированное использование и управление таким инструментарием — актуальная задача [8]. 

В [9] показано, как различные практики управления качеством влияют на инновации в компаниях, сертифи- 
цированных по [$0 9001. Некоторые исследования посвящены учету практических рекомендаций при разработке 
жизненного цикла продукта. Из [10] известно, что 60-80 % потенциальных ошибок при разработке инновацион- 
ных продуктов связаны с неправильно понятыми требованиями. Авторы [11] утверждают, что при обсуждении 
качества продукта следует прояснить вопросы качества кода, стоимости достижения заданного качества и вре- 
мени выхода на розничный рынок. В вопросах автоматизации качества особая роль отводится непрерывной ин- 
теграции (или непрерывной доставке) программного кода [12]. Так называется процесс, который обеспечивает 
постоянное обновление кода при разработке софтверного продукта. В [13] даются рекомендации, как учитывать 
уровень конкуренции в отрасли при последовательном выпуске новых версий продукта. 

Каждая из перечисленных работ рассматривает разные элементы управления качеством. При этом упускается 
из вида системное и структурное взаимодействие процессов. Как следствие, нет комплексного представления об 
управлении качеством при создании, тестировании и доработке ПО. Данное исследование призвано восполнить 
указанный пробел. Описывается комплексный подход, связывающий теорию, практику и методы управления ка- 
чеством в ИТ-сфере. Отметим также, что благодаря гибкости предложенной модели ее можно адаптировать под 
нужды конкретного производителя. 

Роль управления качеством при разработке ПО. Качество — это комплексная категория, которую можно 
рассматривать с разных точек зрения: философской, социальной, технической, экономической, правовой [1]. В 
данной статье качество обсуждается как совокупность свойств товара или услуги, способных в той или иной 
степени удовлетворять потребности целевой аудитории [3]. Продукт рассматривается как суммарный результат 
разных видов деятельности, причем у каждой — свои входные данные (параметры) которые в результате произ- 
водственного процесса превращаются в выходные (ценность). Продукт — это совокупность ценностей. Он пред- 
назначен для удовлетворения потребностей, которые определяются заранее, при маркетинговой разработке то- 
вара или услуги. О качестве продукта судят по тому, насколько реальная удовлетворенность потребителя совпа- 
дает с запланированной. 

В области информационных технологий основными считаются две группы требований к продукту (потреб- 
ности пользователей): функциональные и нефункциональные. Как и на любом рынке, при розничной реализации 
ИТ-решений точно выстроенная работа с ценностью обеспечивает лояльность целевой аудитории, а значит, по- 
вышает рентабельность выпуска программного обеспечения, приложений и аналогичной продукции. 

Реализованные дефектные товары портят имидж производителя [8]. Негативные отзывы распространяются в 
сети и мессенджерах. Потеря пользователей ведет к ухудшению финансовых показателей. Кризис качества может 
обернуться банкротством производителя. 

В [6] показано, что менеджмент качества через управление процессами связан со всеми пятью типами инно- 
ваций. Перечислим факторы, которые их формируют: 

— новая техника и технологии; 
продукция с новыми свойствами; 
новое сырье; 


— новая организация производства; 
новые рынки сбыта. 


Информатика, вычислительная техника и управление 


257 


Брз://уезш-допзва.га 


258 


Бируля М.Д. Управление качеством при разработке программного обеспечения 


Материалы и методы. Научные изыскания, результаты которых обобщены в представленной статье, бази- 
ровались на глобальной практике производства и реализации софтверных товаров и услуг. Кроме того, изучалась 
литература, посвященная созданию и продвижению ИТ-решений. Теория соотнесена с практикой деятельности 
крупнейших разработчиков программного обеспечения. Теоретическая часть дает представление о специфике 
разных методов управления качеством. Приводятся примеры их практического использования при управлении 
жизненным циклом продукта. С этой точки зрения рассмотрены некоторые подходы к менеджменту проектов — 
гибкие, каскадные (второе название — водопадные) и гибридные. 

Исследуется организация и координация релизов (выпусков) программного обеспечения. Это тесно связано с 
управлением качеством, однако редко или фрагментарно рассматривается в литературе. 

Практика реализации крупных проектов соотносится с хорошо изученной теорией управления качеством. Это 
позволяет точно определить, как крупные организации задействуют теоретическую базу для обеспечения каче- 
ства информационных продуктов (а в итоге — для их коммерческой успешности). 

Отметим, что автор данной статьи имеет опыт управления софтверными продуктами, и его профессиональные 
знания тоже использовались в качестве материалов исследования. 

Виды тестирования программного обеспечения. Как показано в [7], на рынке (то есть вне компании-про- 
изводителя) восприятие качества (как элемента конкурентного преимущества) определяется в процессе проекти- 
рования продукта, статистического контроля и обратной связи. Представление о качестве внутри компании за- 
висит от того, какой процент продукции проходит все проверки и в итоге не требует доработки. Этот показатель 
связан главным образом с управлением процессами, а не со статистическим контролем и обратной связью. 

Важно, чтобы элементы системы, влияющие на качество, поддерживались высшим менеджментом и согласо- 
вывались с управлением персоналом. Кроме того, практики работы с качеством и его индикаторы нужно учиты- 
вать при настройках внутрикорпоративных отношений, взаимосвязей с поставщиками и другими контрагентами. 

Для определения качества будущей и готовой продукции проводится тестирование, поэтому важно понимать, 
что именно является объектом испытаний. В данном случае недостаточно сказать: «продукт». Это слишком об- 
щее понятие, его следует конкретизировать. Часто к продукту предъявляют определенные функциональные и 
нефункциональные требования. В первом случае речь идет о наборе функций, которые система должна выпол- 
нять определенным образом. Например, при наборе адреса в строке браузера должна появиться соответствующая 
страница. Выбор определенных элементов меню на этой странице должен вести к заранее известным результа- 
там. При этом может быть несколько сценариев взаимодействия с сайтом — например, для зарегистрированных 
и незарегистрированных пользователей. Так, большинство сетевых ресурсов при регистрации открывают воз- 
можность комментировать посты, получать подборки материалов и пр. 

Как ясно из названия, нефункциональные требования не связаны с функциями, доступными пользователю. 
При этом они часто дают потребителю более весомые преимущества, чем функциональные. Речь может идти об 
определенном уровне защиты данных, комплексном сборе аналитики, соблюдении законодательства (например, 
о защите персональных данных). 

Соответствие продукта функциональным и нефункциональным требованиям проверяется по-разному. 

На рис. 1 представлена пирамида тестирования функциональных требований. Виды испытаний ранжированы 
по важности, скорости, стоимости и доле успешных проверок. 
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Рис. 1. Виды тестирования [14] 
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Юнит-тестирование, или модульное тестирование — это проверка корректности отдельных модулей ис- 
ходного кода программы, отдельных функций приложения или сервиса. В результате устанавливается, работо- 
способен ли код, дает ли он правильные результаты при различных входных данных, соответствует ли логика 
ожидаемой. Пример такого теста: при сложении двух чисел должна получиться их сумма. В функцию вводятся 
входные значения, необходимые для проверки. Юнит-тест пройден, если ожидаемый результат функции равен 
фактически полученному. Для расчета метрики соотносят количество строк кода, прошедших тест, и общее число 
строк кода в репозитории. Лучшим индикатором считается 80 %. Он показывает, что логика любой функции 
соответствует ожидаемой на 80 % еще до того, как начинается следующая стадия тестирования. Значит, про- 
блемы выявляются довольно рано и решаются гораздо дешевле и быстрее. Поэтому юнит-тест — первая ступень 
в пирамиде функционального тестирования. Его отсутствие (как и любых других видов тестирования) создает 
пробелы, накопление которых ведет к необоснованному удорожанию проекта [15]. 

Интеграционное тестирование. На следующем этапе тестируется взаимодействие компонентов будущего 
приложения. Проверяется интеграция модулей. Эти испытания сложнее юнит-тестирования, т. к. проверяется 
возможность выполнить последовательные действия в различных компонентах. Пример: пользователь входит в 
систему — перенаправляется на главную страницу — размещает объявление. То есть тестируются сразу не- 
сколько модулей. Ниже перечислены основные варианты интеграционного тестирования. 

«Большой взрыв». Все компоненты собирают и совместно испытывают. Это позволяет выполнять тестиро- 
вание один раз после разработки. Однако при большом количестве модулей какой-то можно упустить из виду, и 
это слабое место метода. К тому же увеличивается петля обратной связи, так как тестируются готовые решения, 
когда разработка завершена. Отметим также сложности с локализацией ошибки. Они объясняются тем, что при- 
дется проанализировать весь процесс (сценарий) разработки, чтобы узнать причину проблемы. Это значит, что 
время тестирования увеличится. Метод однозначно удобен для небольших систем. 

Инкрементальный подход. В отличие от «большого взрыва» испытания можно начинать, даже если к нему 
готовы всего два модуля, и добавлять остальные по мере их разработки. В этом случае проще локализовать ис- 
ходные ошибки, сокращается петля обратной связи. Не нужно ждать, пока будут готовы все сервисы. А значит, 
проверка начнется и завершится раньше. Устранение дефектов обойдется дешевле. Инкрементальное тестирова- 
ние можно выполнять двумя способами: снизу вверх и сверху вниз. 

Интеграция снизу вверх. Сначала тестируются самые некритичные модули, затем более значимые и 
наконец — базовые. Следовательно, верхние компоненты нельзя проверить, пока нет данных о качестве элемен- 
тов нижнего уровня. Это увеличивает время между разработкой и стартом тестирования. 

Интеграция сверху вниз. Тестирование начинается с наиболее значимых уровней приложения. В данном 
случае испытание модулей нижних уровней может быть не вполне адекватным. Однако даже если впоследствии 
это обернется проблемами, они будут некритичными. 

Гибридная интеграция. Модули разных уровней тестируются совместно. Успешность такой проверки опре- 
деляется тем, понимает ли исполнитель архитектуру приложения и может ли определить оптимальный подход к 
конкретному продукту [12]. 

Системное тестирование. Все компоненты программы испытываются как единое приложение. Специалист 
должен удостовериться, что продукт корректно отрабатывает различные сценарии и ситуации. Этот вариант мо- 
жет включать тестирование нефункциональных требований. Такой подход основывается на требованиях или на 
базе сценариев использования. В любом случае результатом будут тестовые сценарии. Их успешное прохожде- 
ние подтверждает, что система работает именно так, как ожидается. 

Системное тестирование требует значительного времени, поскольку с развитием продукта растет количество 
возможных вариантов ее использования. Следовательно, софт нужно своевременно обновлять. Этим занимается 
служба поддержки. При каждом обновлении продукта необходимо проверить, работают ли ранее протестирован- 
ные функции. Этот процесс называется регрессионным тестированием. Если ранее тесты работали, а после ввода 
новой функции перестали, значит, есть проблема. Процедура такой проверки иногда занимает колоссальное ко- 
личество рабочего времени инженеров по тестированию, и они не успевают писать новые тесты. Этим обуслов- 
лена важность автоматизации испытаний, которые выполняются вручную. При таком подходе тестирование оп- 
тимизируется до простого анализа результатов автоматических проверок. Лучший вариант — это 100-процентная 
автоматизация. Достичь такого показателя не всегда возможно, поскольку некоторые тесты не подлежат автома- 
тизации из-за их сложности [16]. 

Приемочное тестирование. На последнем этапе продукт тестируют ключевые специалисты и заказчики. Они 
в режиме реального времени проверяют, насколько реализованы их ожидания и требования. Выясняется, с ка- 
кими проблемами столкнется будущий пользователь. Все ли функции работают, как было задумано, удобен ли 
интерфейс, насколько вероятны ошибки и некорректные операции. В итоге проект принимается или не принима- 
ется. Приемка — это заключительный этап тестирования. 
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Исправление недоработок и дефектов, обнаруженных на данном этапе, обойдется особенно дорого, поскольку 
для решения проблемы придется пройти весь процесс с самого начала — от разработки и юнит-тестирования до 
полной проверки системы. Следовательно, на более ранних стадиях нужно приложить все усилия, чтобы избе- 
жать такой ситуации. 

Нефункциональное тестирование проверяет приложение на: 

— производительность; 

— надежность; 

— совместимость; 

— безопасность; 

— полезность; 

— масштабируемость. 

Для проверки этих свойств используют более 15 видов тестирования. Назовем наиболее распространенные. 

Тестирование производительности. Оценивается скорость и эффективность работы приложения или си- 
стемы. Основное внимание уделяется скорости ответа на запрос пользователя. Например, тестирование может 
включать оценку времени загрузки основной страницы сайта. Определяются целевые показатели производитель- 
ности, и с ними сравниваются реальные результаты. 

Нагрузочное тестирование. Выясняется максимальная нагрузка, которую выдерживает система без отказа или 
существенного ухудшения производительности. Например, для сайта это означает определение количества пользо- 
вателей, которые могут одновременно взаимодействовать с платформой, прежде чем произойдут сбои или отказы. 

Тестирование отказоустойчивости. Испытывается способность системы или приложения сохранять рабо- 
тоспособность при сбоях или непредвиденных ситуациях. Цель такого тестирования — обнаружение уязвимо- 
стей и разработка мероприятий для обеспечения непрерывной работы. 

Тестирование совместимости. Проверяется совместимость приложения или системы с другим программным 
обеспечением, с различными операционными системами, браузерами и устройствами. 

Тестирование безопасности. Оценивается уровень защищенности системы или приложения от атак и потен- 
циальных угроз безопасности. Выясняется, есть ли уязвимости, анализируются защитные механизмы и эффек- 
тивность мер безопасности. 

Тестирование аварийного восстановления. Определяется способность системы или приложения восстанав- 
ливаться после сбоев, отказов или других чрезвычайных ситуаций. Цель — проверка эффективности процедур 
восстановления и минимизация времени простоя в случае аварийных ситуаций. 

Результаты исследования. В рамках представленного исследования сформирована комплексная модель 
управления качеством при создании ПО. Описаны ее взаимосвязи с жизненным циклом разработки, релизами, 
издержками и моделью менеджмента проектов (гибкой, каскадной или гибридной). 

Процесс управления качеством в жизненном цикле разработки ПО. Стандартная разработка цифровых 
продуктов состоит из шести производственных процессов, или этапов. Каждый из них должен вносить вклад в 


обеспечение качества (рис. 2). 


Тестирование 
Поддержка 


Рис. 2. Жизненный цикл разработки программного обеспечения [17] 
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Анализ и определение требований к продукту. Исследуются проблемы, предлагаются решения с учетом 
заявленных требований. Этот процесс задает основные показатели для проверки готового продукта. В зависимо- 
сти от модели разработки описываются и согласовываются стратегия, подходы и инструменты тестирования. 
Один из документов называется «Видение продукта и его возможности». В нем фиксируются выявленные про- 
блемы, отмечаются связи с бизнес-планом, описывается конъюнктура рынка, перечисляются основные функци- 
ональные и нефункциональные требования. Документ утверждают стороны-партнеры (то есть представители ис- 


полнителя и заказчика). При необходимости в текст вносят корректировки. На этом этапе важно привлечь спе- 
циалистов по безопасности и архитектуре приложений, которые помогут точно определить нефункциональные 
требования, важные для будущего тестирования. 

Дизайн архитектурного и визуального решения. С учетом требований, выявленных на предыдущей стадии, 
вырабатывается архитектурное решение, обеспечивающее их выполнение, и дизайн пользовательского интер- 
фейса. Все это — ориентир для команды разработчиков, которым предстоит тестировать и при необходимости 


корректировать продукт. 

Разработка. Создается код для решения задач и проблем будущих пользователей. Для проверки логики от- 
дельных функций пишутся юнит-тесты. Основная цель — достичь нужного показателя покрытия кода тестами 
(не менее 80 %). Однако широко применяются и другие практики — такие как аудиты кода (сое геулеу\). В этом 


случае код проверяют другие члены команды, и на ранних стадиях разработки ВЫЯВЛЯЮТСЯ ошибки, недочеты, 
пропуски и уязвимости. Ревьюеры могут оставлять комментарии к конкретным строкам кода, указывая на необ- 


хоДимостТь переработки. С точки зрения качества продукта идеальный сценарий — двойное код-ревью, когда 


минимум два не связанных с автором специалиста рассматривают и комментируют код. 

Кроме юнит-тестирования и код-ревью необходимо использовать линтеры. Это автоматизированные инстру- 
менты, которые анализируют код в реальном времени, обнаруживают недочеты, ошибки и предлагают пути их ис- 
правления. Можно использовать и другие виды тестирования в зависимости от стратегии и требований к продукту. 

Тестирование. Инженеры по тестированию разрабатывают адекватные задачам тест-сценарии. Как правило, 
они пишутся вручную, что замедляет реализацию данного этапа. Целесообразно автоматизировать процесс, од- 
нако это не всегда возможно. На данной стадии специалисты проверяют и при необходимости перепроверяют 
результаты ручных и автоматизированных тестов. Особое внимание уделяется случаям, когда автоматические 
тесты выявляют ошибки. Важно установить, реальная ли это ошибка, или ложноположительный результат. Об- 


наруженные дефекты ранжируются в зависимости от их важности для системы или пользователей, а затем пере- 
даются разработчикам для исправления. После устранения дефектов полезно провести анализ корневой причины 
проблемы с использованием метода КСА (англ. гоо{ саязе апа]уз15 — анализ причин). Это позволяет разработать 
меры по предотвращению проблем в будущем, добавить новые юнит- или интеграционные тесты. Для полного 
понимания причин проблемы рекомендуется использовать технику «5 почему» (англ. 5 \!Ву’5). Схема метода 
выглядит так: формулируется проблема и задается вопрос: «Почему это случилось?». На него следует ответ, опи- 
сывающий определенный факт или ситуацию. Вновь задается вопрос: «А это почему случилось?». И так пять раз. 


Пять ответов позволяют приблизиться к пониманию причин проблемы. 
Тестирование — это масштабный процесс. Ниже перечислены его основные этапы. 
. Настройка и конфигурация окружения для тестирования. 
. Написание и выполнение ручных тест-сценариев. 
. Автоматизация ранее написанных ручных тест-сценариев. 
. Проверка результатов автоматических тестов. 
. Поддержка актуальности автоматических тест-сценариев и исправление ошибок. 
. Фиксация дефектов. 
. Документирование дефектов. 
. Анализ причин дефектов. 
. Разработка шагов по предотвращению появления дефектов в будущем. 


со чмлбмяияьь- 


Развертывание кода приложения. Программное обеспечение требует различных сред для развертывания. 
Важно хорошо представлять, как непрерывная интеграция и непрерывное развертывание (англ. сопйпиоиз п{е- 
этайоп ап4 сопипиои$ дерюутепт, СИСО) обеспечивают стабильное качество ПО при минимальных трудозатра- 
тах. Этому способствует в первую очередь автоматизация развертывания кода — перенос его изменений из одной 
среды в другую. Процесс делится на этапы, которые зависят от продукта, организации и принятых стандартов. 

Степень автоматизации, количество и строгость проверок определяют ожидаемое качество продукта до того, 
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как код станет доступен конечным пользователям. На рис. 3 показана возможная схема развертывания кода. При 
высоком уровне автоматизации трудозатраты будут минимальными, придется выполнить вручную всего не- 


сколько проверок. 
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Рис. 3. Схема процессов и проверок при развертывании кода 


Следуя представленной схеме, можно контролировать качество и автоматизировать развертывание кода. Это 
позволит сократить время на разработку, а значит, продукт быстрее выйдет на рынок. 

Поддержка продукта. На этом этапе необходимо выстроить обратную связь с пользователями: проводить 
опросы, собирать и анализировать метрики. Все это будет базой для задач и идей по улучшению ПО. Предполо- 
жения следует подтвердить А/В тестами, т. е. сравнением вариантов продукта. Важно также обеспечить обрат- 
ную связь с командой поддержки, которая напрямую контактирует с пользователями. Именно эти специалисты 
делятся ценными наблюдениями, передают пожелания целевой аудитории, на основании которых проводится 
анализ и формируются новые стратегии. Как видим, процесс не завершается, даже если продукт полностью готов. 
Появляются новые данные для анализа, сбора требований и развития цифрового товара или услуги. 

Обсуждение и заключение. Представленная в статье модель управления качеством адаптируется под нужды 
различных организаций и продуктов. Можно дополнительно изучить ее компоненты, чтобы создать оптималь- 
ный план для достижения целей, связанных с управлением качеством. При этом следует иметь в виду ключевые 
факторы коммерческого успеха ПО: разработчики и тестировщики должны критически мыслить, наладить со- 
трудничество и постоянно совершенствовать процессы. 

Предложенная модель предполагает стратегические изменения, реализация которых требует значительного 
времени, поэтому общий процесс трансформаций следует разбить на части. 

Изложенный материал будет полезен менеджменту, который курирует вопросы качества, касающиеся общей 
стратегии компании и оптимизации отдельных процессов. 

Отметим, что для достижения значимых результатов необходимы высокая степень автоматизации тестирова- 
ния, развитая инженерная культура и значительные затраты на создание и поддержку инфраструктуры. 
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